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BALLOTS (Bibliographic Automation of Large Library 
Operations using a Time-sharing System) is an on-lii^ interactive 
library automation system that supports the acquisition and 
cataloging functions of the Stanford University Libraries' technical 
processing operations. The BALLOTS system is being implemented in a 
series of 11 modules. This papei- describes the first module, 
BALLOTS-MARC, or simply the MARC module, and various aspects of 
system hardware and software as they pertain to this i-jodule. The MARC 
module supports the production of purchase orders, catalog card sets, 
spine labels, and ssveral ypes of file slips and managen.snt reports. 
An on-line msc file stored on disk is updated from the weekly 
Library of Congress MARC tapes. Several indexes are maintained in the 
fxle in order to support extensive on-line interactive file 
searching. One way of describing BALLOTS is to explain how the system 
lo(^s to the user and how it is used in normal day-to-day library 
operations. A typical book cycle will be traced in the examples that 
follow. (Other documents on BALLOTS are available as ED 038 153, OHH 
049, 049 786, and 060 883.) (Author) 
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IMTRODUCTIOM 



^h = ^ an on-lin^ interactive library autoniation system 

sJanfor7nn ' ^^f/^??'^ ' ^ ; on and catalo.in;, functions of the 
Thp RAi inr^ " r'^'-'^''?'''^' technical processing operations. 
I^H.M '^'^""^ " ^^'"^ Implemented In a series of 11 

modules Tnis paper describes the first module, "RALLOTS-MARr" 
(or slnoly 'the MARC module"), and various aspects of system 
hardware and software as they pertain to this module ^he MARr 
iT. implementation In the late umme^ of 

oper;tIon Th^'^h'^' P>j^ ished Proceed I n.,s. It should be In 
of this o^oeJ " ' described at the end 

r^t. J^'' fuPPorts the oroductlon of purchase orders, 

In/l/' ' l""^^' '"""^ ^^"^ -^^^^--3^ types of file slips 

Tho BALLOTS systen operates through programmable CRT 
(cathode ray tube) terminals In the library that arp 'connected to 
the Campus Facility I RM 360 Model r,7 computer in the Stanford 
Compu at.on Center, approximately one mile away. Tho Campus 
Facility computer also -candles the faculty and stuHpn- acadenlr 

Cn'^at^r^o R7L0^^5 -.uirements. .bout 7, 000 co^put Inf ibis 
un.eiatei to RALLOTS are run on this computer each day. 

The tyoe of video display torminal beln,^ used for BALLOTS 

Library communicates with the system. Printed outo.jt^ ^h. 
purchase orders, catalo. cards, 'and 1 ne label srare orod. cei 
te™K ' °' ''''' '^"-^'"^ activity It the 

Inn...'^^^ 72"^ ^escribin, BALLOTS Is to explain how the system 
looks to the user and how It Is used In normal day-to-day library 
ooPrations A typical book cycle will be traceH In the "^'^'^ 
examples that follow. 



*B!bl!oTraphlc Automation of Lar^e Librarv Onsrations uslnr 
a Time,-shar,n<r System. A lar;^e oart of BALLOTS develoompnt m ?o 

h: 'rVT"-r"%'r' '-^-^^ ^"nded by a%?ant ^rom 

.^nd ;,';r' '^''-cation, ^epartmPnt of Health, Education, 
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SEARCHING 



A typical book processing cycle begins when the Acquisition 
DepartP^ent receives a book request from a faculty or sta^f member 
requesting that a particular book be added to the collection. A 
sample book request Is shown In Figure 2. On receiving the book 
request, the Hbrarlan keys la a search request for that 
particular book at the CRT terminal keyboard. Thij search 
request, shown shaded In Figure 3, Is displayed on the CR"i screen 
as It Is keyed. (In the following figures, all the data supplied 
by the terminal operator Is shown shaded; all the data supplied 
by the computer Is shown unshaded.) Tne operator In this example 
chose to search ("find" or "fin'*) by one personal name ("pn"), 
and because he was unsure of the spelling of the author's name 
{'Mon" or "John"?), typed "J." Instead. The operator chose two 
words ^^rom the title. Because he was unsure of the spelling of 
"Cortes," he truncated the word to "Corte#," which would locate a 
record for any title word beginning with "Corte." 

The s»;^rch request Is entered into the system, the on-line 
MARC File is searched, and the search results are returned to the 
screen In about two seconds. !n the BALLOTS system, when only 
one record Is found in a search. It Is assumed that this record 
is the corre'^t result^ and the full bibliographic record is 
displayed at the terminal (Figure k) . 

Searching can be done using any word or words in the title 
(trivial words, like "the" and "In," will be recorded In an 
exclusion list for the file, and the system will reject them as 
search terms). One can also search using the Library of Congress 
card number, the main entry, the title statement, and added 
entries. And the personal name can be given to the system In 
various forms. For Instance, In Figure k the author's name 
turned out to be stored In the KARC File as "White, Jon Ewbank 
Manchlp." The following variations on this name, or any 
combination of them, would also be accepted as valid search terms 
and would locate the same record: 



WHITE, J.E.M. 
White, M. 
White, J E M 

white, J on ewbank manchlp 
J. P.M. White 
ManchI p Wh i te, J. E. 
White, Jo Ewb Man 



(Initials) 

(some Initials omitted) 

(Initials without periods) 

(capitalization Ignored) 

(surname first or last) 

(surname first or embedded) 

(first names Implicit trunc 
St I on ) 



i ^— 


White, Jon M. ^s^lAi^T) 

TJ«»« Cortes and the Downfell of the Aztec 
Empire 






n»t« PuUttktr 

Nev York St. Martin** Press 



Dttc cf ruMittli«n j Nc V9T1 

1971 i 



X I 

R»9 hr JMR^ . 



aijp^ 

Fufvl 



Pl/jurc 2, Book Request 



Figure 3. A Search Request on the SIOl Screen 



SI 01 BMRC-S 



ORDER 



<5F01 RMRC-S 72U058<1 ORDER S WFD 

fin pn j.M. White and t Corte# and Aztec RESULT: 1 BOOK(S) 

ORni 

Whitft, Jon «^whank Manchip, l<i7U- 

Cortes and the downfall of the Aztec ^niplre; a study In a con'Mct of 
ciiltnros, hy Jon f1;jnchlp White. New York, St, Martin's Press [l^7\] 

^5? P. Illus., niaps, plans, ports. 7.S cm. ^lO.no 

RIM loj^raphy: p. [3^5]-33<5. 

1. Mexico - History - Conquest, I51<5-15li0. 
I. TITLH. 

F1230.Ul*6 1071 q7'>/.0?/n92'i 
CPinyji LiAnpr RPCran MS:N 



2, Cortps, Hernando, TU«5-15^7. 



Figure k. A Full Bibliographic Display on the 8F01 Screen 



(last name explicit truncation 
through use of oound ss9:n) 



The BALLOTS system makes extensive efforts to recognize different 
versions of a personal name, because In many of the library 
processlnp; cycles the exact name of an author Is not known. This 
helps to ensure success In on-ltne search 
efforts . 

If the search in Figure 3 had been entered as simply "fin pn 
J. M. White/' the search might have produced more than orse^ 
result (because more than one record in the data base ful'^illed 
the search criteria). In this case (FIp,ure 5), the results would 
be displayed as a numerical total of the number of records found, 
rather than the first of these records beln^ displayed In Its 
entirety. Figure 5 shows a total of five record's found that meet 
the search crfterla. The librarian now has the choice of asking 
for each of the ^ull bibliographic records to be displayed in 
turn, or of keying additional search criteria that, when added to 
the prevloiis search request, would reduce the number of records 
^ound. This second option is shown in Figure 6. Such iterative 
searching would oroduce the same result as displayed In Figure 
Figures 5 and 6 Illustrate (very simply) the Interactive 
searching caoabillties of the system. 

ORDERING 

If the search described In the previous section has produced 
the desired record, and the library decides to order the book, 
then the terminal operator requests an ordering (OROl) screen for 
the same bibliographic record. This Is shown In Figure 7. The 
terminal operator fills in the appropriate Information: vendor 
data, accountlnt^ data, and enough additional information to 
produce a ourchase order. In Figure 7, the values in the 
unsha-^ed fields were supplied by the system as default options: 
"po" (purchase order) for the method of procurement, "01'' for the 
address code (stands for Stanford University), "2" for the 
special notification Indicator (Indicates that a notice Is to be 
sent to the requester when the material Is received), and "WED" 
for the searcher's initials. The system also supplied a request 
for one copy ("1 c") and the price ("UO.OO"), but the operator 
has changed this to "2 c." and "$20.00." 

Many of the Items on this screen are coded, since a 
considerable amount of repetitive data Is Involved in the 
day-to-day use of this screen. For Instance, instead of putting 
In a specific vendor's name, a vendor I.D. is entered; the system 
uses this I.D. to look up the vendor's name and address In 
another file. 

In the example shown In Figure 7 there are three errors In 
the Inout. When the operator has decided that the ordering 
I nfor'f'dtion Is complete and has tranj^mltted this Information to 
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» 7. PreparJnr, Purchase OrH*»r on the OROl Screen 




the conpMter (by d-^press i n*: thft "SENH" button on the keyboard)^ 
RALlOTS nrnxrann per^orn on-line eHltlni^ of all the 'lata elements 
on the screen. As part of this, ^or Instance, the ^•.•1r:et account 
coie (""A'^") is scanned and the codes and values file is 
searr.he'^; this check reveals that the data contains an invali-^ 
code. As a result, the orderlni^ screen Is returned to the user. 
An «rror co ie, indicatinp: the invalid code, appears on the screen 
precedint' th'^ i^AC field. ?^rror codes are also returned to the 
operator ^Indlcatin'^ that the vendor I.D. Is an Invalid code and 
that a fi'ild v-^h'^re a data element value Is required Is blank (the 
shelvins iocatior. f i eld— "SHR") . When the screen Is edited, the 
syst'^T movps the '^irst line containIn>; an error up to the 
position n<= fourth line on the screen. The correct lines above 
ft ar'=' not displayed. When these errr.rs have been corrected '(see 
Fip:u'-e «), the screen Is sent a second time to the computer and 
the data is then accepted. 

Once the final screen needed to perform a function Is 
accepted by the system, the transaction is consIdere'^ complete 
and the system pro-nots the terminal operator to .q;o on to another 
activity by responding "ENTRY PROCESSED" (see Fi«^ure 9). As a 
result of the successful on-line activity shown In figures 3-9, 
several outputs are printed overnlj^ht in the computer hatch 
partition. These outputs are the purchase order (Fl.^ure 10), a 
catalop; work slip (Fi.<^ure 11) for use by the Catalog Department 
\-/hen the book arrives, an^ a temporary order slip (Flp.ure 11) for 
use by the Acquisition Department. 

'/e have looked at a tynlcal BALLOTS orderlnp; cycle. Thf: 
catalo.Mn<T cycle consists of a similar sequence of searchinp;. 
Input (usi'n<3 some different screens), and output. This cycle 
will be discussed in a later section. 

J^f pqo^.RAMMARLE CRT TERMINAL AND BALLOTS SOFTWARE CAPARILITIPS 

Several basic functions of the BALLOTS system were 
Hprnz-nstraf^d In the activities just described. But this 
Into'-actlon between the user and the CRT terminal Is only the tip 
of th- irpber^ that Is the BALLOTS system. Havlnp; looke-^ at some 
initial uses o<= BALLOTS, we can now ^ little furthr- into some 
comoonents of the system. 

The terminal used In the BALLOTS system is the Sanders PDS 
nOh oronramnable CRT terminal. This terminal InHudes a 
microorocpssor in Its hardware that oermlts specific computer 
programs to be loaded di recti" Into the CRT terminal. Thes.i 
programs control the display of data entered at the keyboar' and 
the communication of the terminal with the main computer. The 
Sanders CRT terminal can display 1,920 upper- and lowercase 
characters on a screen. In 2k elp:hty-cbaracter lines The 
BALLOTS development staff were able to assign specific functions 
to certain keys (such as the paging keys--5ee the last paragraph 
under "PROTOCOLS AND COMMANDS"), to adapt the Sanders terminal to 
the uses of the system even further. 
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conflict of cultures, by Jon »:anchip i.'nite. Ueu York, ot. 
Martin's Press (1071 ) 
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FUure 11. Worksllp 



^iOl'i Fll.r. 10/ 15/72 72K0539 

..'hite, Jon Ewbank r-anchip, 192^- 

Cortes and the downfall of the Aztec £ni^ire; 
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"anc'^ip .«hlte. .*iew York, St. Martin's f*ress 
[1171 j 

F1250.,/UG 1571 
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Figure 12. Order Slip 



The BALLOTS terminal Is programmed so that specified 
sePiTients lines on the screen or rant^es of lines on the screen 
can he considered as sln.^ile data element fields. These fields 
may he either protected or unprotected. A protected ^ield Is one 
In v/hich the user cannot input data, al thouj^h the system may 
display data there- Ourinr, input at the keyboard, the cursor is 
prevented from entering; protected fields; this constraint Is part 
of the control prop;ram loaded In the terminal. (The cursor Is a 
fast-bl i nki n<5 underline character that Indicates to the user his 
position on the screen-) When the user is typing data In a 
field, ho cannot type oast that field Into another field unless a 
''CR" ("carria^^e return") or "TAB" key is depressed. A "f^R" will 
move the cursor to the first input position on the next line; a 
lov/ercase "TAB" will move the cursor to the first Input position 
of the next field (which may be on the same line or the next 
line). An upper-case "TAB" moves the cursor back to the 
bepfinnint^ of the current field. If the cursor Is already at the 
he<=:inninp: the field, it is moved to the he^innins: of the 
orevious Input ^ield. 

It should be pointed out that all of the features described 
here are orogrammed into the terminal and are not part of 
the hard»'/ired logic of the terminal. This flexibility was one of 
the primary reasons for choosing: the Sanders prof^rammabl e 
termi nal . 

There are Vio types of input fields In the BALLOTS system. 
One »s a fixed-length field and the oth'^*' Is an expandable field. 
!n a r ixed-1 en<^th field, the amount is predetermined, 

and only the maximum number of characters allowed for that field 
may be entered. If the user continues typing, the cursor will 
not move to the next field, but will remain at the last character 
position in the current field. Each additional character input 
will simply overlie the previous last character. The only way to 
^et to the next field is to hit a "TAB" or "CR" key. 

If data is being input to an expandable field and there is 
not enouo:h room preal located on the screen, the user keeps 
tyoln^^. As soon as the first character beyond the current end of 
the field Is keyed, the microprocessor recognizes this and 
immediately inserts a blank line followin.f^ the overflowing field, 
so that the continued data Is input in this new line- (An 
expandable field always extends to the end of the line.) All the 
lines on the screen below the overflowmg field are consequently 
pushed down one line on the screen, whether they are protected 
(the cursor cannot enter them during input) or unprotected (the 
user may alter their contents). Thus the user need not watch^rhe 
screen to see where the "end" of an expandable field falls, since 
the computer will provide however much space Is needed to input 
all the data. 

Sometimes, when an input field expands beyond a single line, 
the last word on a line may be split and continued on the next 
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line. Althou.q:h this presents no problem ^or the computer 
soft^vare^ it is difficult for the user visually to verify the 
screen and is aesthetically displeasing. The microprocessor 
soft»-/ar*=» will therefore automatically adjust the data in the 
fields reconnect i njs: the broken word by movin/^: the ^irst half of 
the v/ord from the previous line down to the succeeding!; line. 
This adjustment takes olace as the user is keyin;; data. 

SCRFEN FORMATS 

Given these basic features of the terminal software^ we can 
look at the actual screen format developed for BALLOTS. The 
orderin*^. (OROl) screen (Figure 7) is the example used; but the 
rules an^ methods described here apply to all o^ the BALLOTS 
screens . 

1. The first horizontal line of the screen is Cc^illed the 
control line; it consists of the following fields. 

a. The first field Is the screen identification: 
'•OROi.** This l.n. identifies the screen format to both the user 
ani the comofjter pro<^rams. 

b. The second field is the file 1.0.: *'BMRC-?." This 
I.D. notifies the user that the RALLOTS-MARC Pile for Stanford 
is b'^in'^. used in displaying the data, 

c. The third field is the record I.D.: "7?l«i0589. The 
search that preceded the use of the ordering screen obtained a 
specific title. The record 1.0. of this title in the MARC File 
is ^*7?iU0589** (this is also its Library of Congress card number). 

1. The fourth field is the function code: '^ORD^R.^' The 
user suoplies this information^ which describes the type of v/ork 
the^ user will be performing (in this case^ ordering). (The use 
of th?s field is described in "PROTOCOLS AMD COMMANDS/* bplow.) 

Th':^ fifth field Is the library identification: '^S/* 
for Stanford University. 

f. The sixth field in the control lin^ is the t'-^rminal 
operator's initials: '^WF.O.** 

2. The second line on the screen is called the message.- 
line. This is used by the system to send messages to the user. 
In it the search a rgument is red i spl ayed^ together wl i b the 
search results (see figures h and 5). Other possible messages 
incluie a warning that the system "/ill be shut down in thirty 
minutes^ or any other commun i cat ic. that is reauired from the 
co'^iputer system to the operator. 

The third line is the command line; it is used for 
communication from the terminal operator to the conouter. This 
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couH he a request to conduct a specific search or to display a 
specific screen. An entire connand 1anf:ua<^e has heen developed 
for the BMLOTS Gysten that includes conrnands for searching, 
reauests ^or screens, lo<^;^inp; on ani off the systf^m, pa?^in^ 
conrrifinds, etc, (Some of these commands 'v!ll he discussed helov/.) 
Uses oT the coinmanti line can he sef^n In fi^^ures 3, an^ 6, In 
Fin:ure 3 the convrir-^nd line has heen used to reqiiest a search; in 
Fl'^ure '4 it has heen used to request an ordorinp^ screen; in 
Fs^-ure ^ it ^as heen used to add parameters to the search in 
oro'^^ress . 

U. The remaininq; lines on the ordprIn<r screen contain 
fixed-length or expandable fields. If the ^ i xed-1 en^^th fields 
are short, more than one field may be placed on the sane line. 
This* is shown in fi<^ures 7 and 8, ^/hen a ^leld is exoandahlp. It 
must h^ thp only field on a line. The *'CAT'' field is an '^xamole 
of this. The end of a fleH is shov/n on the serpen by a ^\ " 
The temporary end of an expandable field is shown by a " in the 
last space on the line. 

The first eip:ht positions (character soaces) precedin^^ each 
innijt ^^leld on the screen follow a consistent patt^^rn. The first 
two positions are for the error code for the iata element. If 
after a screen has been transmitted the on-line editinp; detects 
an error, an aporooriate error code will be displayed in these 
first two positions (see Fij^ure 8). Position 3 is usually 
protected, althouf^h it may be used by the operator in certain 
cases to indicate updated data elements. Positions 5, 5, and 

7 contain the data element mnemonics ( r I ^^ht- j us 1 1 f I ed ) . Position 

8 is blank and protected. Frr.m position 9 to the mark is the 
user inout area. Some lines may contain more than one 

f ixed-lenq:th ^ield» In these cases the position allo'vance Is the 

same for error codes and mnemonics (see "SHE" on the "BAC" line 
in F i -^ure 8 ) . 

PROTOCOLS AND COMMANPS 

^^n 'Elaborate system of protocols has be^n developed in the 
BALLOTS system. A "protocol" is a lof^Ical sequence of operations 
performed at the CRT terminal, requiring specific screens. The 
function code in the control line ("ORDPR" in the preceding 
examo 1 e ) dete rm i nes wh i ch p ro tocol tha terminal ope rat or will be 
f ol 1 owl nq;. These protocol s prescribe the availability of screens 
and commands to various parts of the library. Some screens are 
used only for display; others are used for input gnd uodate. 
Someone in the Acquisition Department v./ould not be making changes 
to the hoHin^s portion of a record; therefore, tho holdin^^s 
(HHOl) screen ^/ouid not be available to that department. On the 
other hand, the Acquisition Department v/ould use the orderin.^ 
screen in order to input vendor Information and pricing 
information; but the ordering screen would not be available to 
someone in the Catalog Department. 
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In addition to determining the uses of the various screens, 
the orotocol system presents a logical sequence of screens to the 
terminal operator for each particular function. These screens 
are default options, and If the user does not request a variance, 
they are automatically displayed one after the other as each is 
successfully completed. For example, on the third line of Fi^^ure 

the orderinp; protocol automatically supplies the next screen 
request for the ordering; (OROl) screen; this is the default 
request followinp: the display of a full bibliographic (BFOl) 
screen , 

A protoccl map of the ordering function Is shov/n in Figure 
13, This is a simplified diagram representing the protocols 
(seqi;3nces of operations) possible in ordering* The default pa:' 
is shown by the heavy line,- and the available options are shown 
by li'^ht lines. The options available at any oolnt in the 
protocol are shown on the horizontal line just below each CRT 
screen. For example, when the full bibliographic (BFOl) screen 
is in use, t^^c user may: 

1. Go directly to an ordering (OROl) screen (default 
option) 

?. Page to the next bibliographic record of several found 
In a search 

3. Request a bibliographic input (BIOl) screen 
Request a supplementary Input (BI02) screen 

5. Begin a new search 

6. Continue interactive searching (SI 02) 

7. Request a fresh search (SI 01) screen 

Each protocol automatically displays certain commands in the 
third line of the screen; these can be changed by the user if the 
defatilt option is no: desired, (This will be illustrated below. 
In "CATALOCI N'G.") There are several types of commands. One type 
tells the system which screen the operator wants to use next. 
These commands are Simply the screen l,D.'s (SI 01, WHOl, BIOl, 
etc. ) 

A second type Instructs the system on how to handle the ^ 
contents of the current set of screens. For example, the ^'enter'' 
command would caiise all of the data elements on the current screen 
and on all orevioiis screens used for the same bibliographic 
record to Sp processed and used to update the file. The ''cancel ' 
command would cancel all the steps taken so far by the current 
protocol • 

A third type Is the search commands. These commands use any 
of th^ available file indexes; search terms can be combined by 
using the logical operators ''and,'' "or," "not." An example of 
the first of these logical operators is shown In Figure 3. Here 
all three criteria must be satisfied In each record found. If 
the ooer^tor is not sure of a search term, he can Input likely 
alternative terms, using the "or" operator. This approach will 
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Figure 13. Ordering Function Protocols foi 
(see Notes on attached sheet) 
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bibl iopiraphic display screen will appear for the next honk, with 
"p''ITRY PROrPSSf^n" and the search comnand ii splayed in fie -riessap:?* 
1 i ne ( n HP 2 ) . 

As a result of the catalopjng activity, a set of catalog 
-:^rds .inH soine labels will be produced. The default option 

4 K, system in the "CT" (catalog cards) and "SL (spinf; 

-^-t fields in Figure 18 signified "yes" to the 
"'■^^Is is done in an overni<^ht batch 

' '^'-^ ^ = talog car-^s 
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The s^aHed portions of the figure are those aspects of the 
full systt^n that are {ncornorated fn the BALLOTS-MARC module. 
This first nodule handles the ordering and catalogin.«5 of titles 
found in the MARC File, The MARC File shown in Figure 23 is 
preceied by the number 1, This Indicates that the MARC File is 
available in the first module. The output documents produced by 
the RALLOTS-MARC module are Identified In the same way. These 
incliiie purchase orders, catalog car^s, spine labels, process 
slips, standinq; search requests, and certain statistical and 
manapi'^men t repor ts . 

The standin.<^ search request capability o^ the MARC module is 
a con ven t '^^nce to the library and performs a unique "SO!'' 
(selected dissemination of information) function for a specific 
titlo. In a search of the i^ARC File, a title may not he found 



•5;, ani 5. This no'lule i)rocesses approximately 55 percent of 
Stanfori's acquisitions nnd 26 percent of its cataloa:ing. The 
perc^^nta^^e of support to net\/ork library processin.9; (aKain, see 
''CLA:>" helo'v) is sli^^htly larger that the Stanfori fip:ures in 
this and later -nodtjles. 

2. In Process I- i 1 e (IPF). This module adds an in process 
file and additional printed outputs. Only MARC material is 
handled; when a record is found in MARC it is transferred to the 
! PF hiid is retained there as an updateahle record throughout 
technical process i n,p;. Since the recorcl will not he pur,p^ed frofn 
the ^^r until module 3 has been implemented, the I PF will 
represent all titles ordered and cataloged by the library us»nj^ 
the automated system, A record in the I PF can be used af.ain if 
additional copies of a book are ordered. 

'j . "^--italoxH; Data FMe (CDF). This module involves buildin.e; 
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percent of cataloging. Modules 1 
of '^7 percent of acquisitions and 
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82 percent of 



process a 
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7. Rook Catalog. This module can be used to create 
bool< catalog done in the Stanford format. At Stanford it 
allow the Meyer Book Catalog to be produced directly from 
thout go i ng 



through the punched card process presently 



any 
wi 1 1 
the INV 
used . 



8. Standing Order and Out-of-Print Desiderata. The 
capanllity of establishing standing orders (SO) and receiving the 
non-sprial materials arriving with SO ' s will be added with this 
module. In addition, out-of-prlnt items (OP) will be added to 
thp IPF, and search-and-quote letters produced for OP dealers. 
If an OP item can be procured^ It can be ordered using the recora 
already in the iPF. 

Automatic Claiming and Canceling. This module adds 
proFr.^ms to review IPF records automatically to determine if 
ordered material is overdue. Material may be claimed several 
times and finally canceled if the dealer does not respond. The 
Acquisition Department may override a scheduled claim or a 
cancellation. The department may also initiate an unscheduled 
claim or cancellation. 

'0. Circulation. This module is designed to handle the 

- - ■ >- ^ ' 1 1 s t i on system. Using 

~ - v i r p 
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CLA^J (CALIFORNIA LIBRARY AUTOMATION NETWORK) 

The features of the BALLOTS sycten have been kept as 
f-ener^il i'ze.i as possible, so that the system could be adopteJ by 
other libraries for their use. At the present ti.^ie, the staff of 
two autononous libraries at Stanford (The Law Library ani Lane 
fleriical Library) an.i of five libraries In the San Francisco Bay^ 
nroa ar^" preoarinti; for the implementation of parts of the BALLOTS 
system in their libraries. These libraries have been revi^win.p; 
the BALLOTS specifications in order to note any chanj^es or 
additions they require. To date, the nu-iber of these chan-es 
seems to be very small, and they do not represent any substantial 
modification of the BALLOTS system. Assummg adequate funding, 
the plan for network implementation is as follows. 

For the first four to eight months after a module has been 
implemented an j placed in operation at Stanford, it will be 
closely observed and monitored. During this period, thi= network 
version of the module will be checked out and tested for network 
use, an-l the network libraries will install equipment and conduct 
trainin.p; classes and acceptance tests. ''/hen all this is 
completed, the module will be put into network pilot operation. 
Thus, the module will underf;:o four to eight months of heavy use 
in its ori'^inal version prior to its network installation. This 
\^ill reduce i.iplementati on time and effort for the network users. 
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(Thp fonov/In<^ publications describe the lnltt.^1 planning 
nnH •l.^sK'^nlnp: of BALLOTS, the Hevel opnent of tlrr proposed net-mrk, 
nnH thp evolution oF the system frorri nR7 to 1971.) 
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